Object-oriented systems instantiate objects based on class definitions. The class definitions specify what features are common to every instance of a class. Recently, it has become common in languages like Microsoft C# for class definitions to specify at least three types of features—properties or data, functions or methods, and events or messages. Additionally, certain object systems create well defined metadata associated with each class that can be used by other objects in the object system to interact with objects from other object systems that were not previously known. Single language computing environments ordinarily support communication only with native objects instantiated from their native language class definitions.
Virtual machines are self-contained operating environments that behave as if they are separate computing devices. For example, a Java virtual machine (VM) implements a Java object system while a Microsoft .NET Framework implements the .NET object system. In a Java VM, all objects are defined by the Java language. In a .NET VM, objects may be defined by a number of different languages including C# and C++, but all such class definitions must be compiled to produce object code and meta-data compatible with the .NET Common Language Runtime (CLR). Certain foreign objects can be created and manipulated within a virtual machine using special APIs or by creating an adapter class that is compiled in the native environment of the VM but communicates with a foreign object.
Unfortunately, problems may arise when it becomes necessary for an object in a single language computing environment to communicate with objects created in a virtual machine's foreign object system that uses a different kind of meta-data or with objects created in a foreign class system. Generally, it is not possible to work with foreign classes that are not specifically compiled to work with the native object system or else interaction with the foreign objects is limited to communication through a special API, such that the foreign objects do not behave as if they were native objects. For example, it may be possible to construct a foreign object through an interface, but the syntax is different from that used to construct a native object. It may not be possible to create a subclass of a foreign class such that the subclass belongs to the native class system. For example, the MATLAB R12 modeling environment may provide a feature for creating a subclass of a Java class, but this subclass belongs to a special object system separate from the regular native object system. Similarly, MATLAB R12 also does not permit Java to subclass a MATLAB class.
In addition to foreign object systems not using the same meta-data as the native object system, foreign object systems frequently use different memory management and different physical layouts to store data belonging to objects. Typically, languages like C++ and Java, and object systems like the Microsoft Common Language Runtime (CLR) require that all objects conform to certain requirements on how their data is managed in memory. Language syntax native to these languages and systems is expected to be compiled directly to code based on and assuming the standard memory management system. This approach may make it difficult to use native language syntax to manipulate foreign objects which may use different memory layout, different memory managers, or even different memory devices.